System and method for communications in a distributed computing environment

ABSTRACT

A system for communications in a distributed computing environment is provided that includes an application layer ( 132 ), a proxy layer ( 134 ), a reference layer ( 136 ), and an object layer ( 138 ). The application layer ( 132 ) provides communications between an application ( 108 ) and an operating entity. The proxy layer ( 134 ) provides communications between the application ( 108 ) and a remote proxy ( 154 ). The remote proxy ( 154 ) is a local representative for a requested object ( 110 ) residing in an address space different from an address space in which the application ( 108 ) resides. The reference layer ( 136 ) provides communications between the remote proxy ( 154 ) and the requested object ( 110 ). The reference layer ( 136 ) includes communication protocol details to support transmission of messages across a network ( 106 ) linking the remote proxy ( 154 ) and the requested object ( 110 ). The object layer ( 138 ) includes the requested object ( 110 ). The object layer ( 138 ) maintains the separation of communication protocol details within the reference layer ( 136 ).

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to the field of software systems, andmore particularly to an improved system and method for communications ina distributed computing environment.

BACKGROUND OF THE INVENTION

Object oriented programming is a method of programming that abstracts acomputer program into manageable sections. The basis of object orientedprogramming is the concept of encapsulation. Encapsulation is amethodology that combines the subroutines, or methods, that manipulatedata with the declaration and storage of that data. This encapsulationprevents the data from arbitrarily being accessed by other programsubroutines, or objects. When an object is invoked, the associated datais available and can be manipulated by any of the methods that aredefined within the object to act upon the data. The basic component ofencapsulation is a class. A class is an abstraction for a set of objectsthat share the same structure and behavior. An object is a singleinstance of a class that retains the structure and behavior of theclass. Objects also contain methods that are the processes that instructan object to perform some procedure or manipulation of data that theobject controls. Classes may also be characterized by their interfacewhich defines the elements necessary for proper communication betweenobjects.

Distributed computing allows an object in a first computer system toseamlessly communicate with and manipulate an object contained in asecond computer system when the computers are connected by a computernetwork. The second computer system may also be referred to as anotheraddress space. Sophisticated distributed computing systems have removedthe communications burden from the computer programs, or objects in anobject oriented programming environment, and placed it in a mid-leveloperating system that manages communications across a computer networkto facilitate a client system's (first computer system) access to andmanipulation of data contained on a server system (second computersystem). The server system could be a computer in a different addressspace and remote to a user on the client system.

Distributed computing and object oriented programming have led to thedevelopment of distributed object management systems. These distributedobject management systems are generally referred to as object requestbrokers (ORBs). When an object on a client computer system requestsaccess to an object that exists on a server computer system, thedistributed object management system provides the communication linkbetween the two computer systems and, thus, between the two objects. Thedistributed object management system removes the requirement of theclient object communicating directly with the server object. Instead,current distributed object management systems utilize a remote proxyobject on the client system which models the interface of the serverobject. The client computer system that requested access to the serverobject communicates with the remote proxy object that exists on theclient computer system. Therefore, the client computer system canoperate as if it is communicating directly with a local object. Theremote proxy object contains the necessary communications information toallow the client computer system to access and manipulate an object thatactually exists on the server computer system. Remote proxies allow theclient system to disregard the location of the requested object and thecommunication details.

A proxy is an object that has an interface and method list identical toanother object. However, it does not contain the same detailed computercode. Instead it contains communications requirements that allow theproxy to communicate directly with another object without knowledge ofthe requesting object. Proxies can be used to control access to certainobjects. They may also be used to remove the labor of distributedprocessing communications from local objects. For example, if object Aresiding on a first computer system needs to communicate with object Bresiding on a second computer system, object A must know the location ofobject B and have the necessary computer code to initiate communicationswith object B. A proxy for object B located on the first computer systemallows object A to simply communicate with the proxy of object B as ifobject B resided on the same computer. The proxy for Object B has allthe necessary information and computer code to communicate with the realobject B on the second computer system. This type of proxy is known as aremote proxy since it exists on a computer system remote from thecomputer system that contains the requested object.

Systems heretofore known have required all possible remote proxies to bebuilt when the software system is initially compiled and loaded onto acomputer. This process can be very time consuming and the resultantremote proxies can require large amounts of computer storage. Inaddition, software system designers must predict every possible remoteproxy that may be needed in the future so that it can be built when thesoftware system is loaded. This process does not allow a system to adaptto its usage and environment.

With the rise of distributed computing systems, client/server computing,and internet/intranet interactions, internode communications betweenapplications and objects has become a necessity. Early operating systemslacked support for inter-application communications, forcing softwaredevelopers to write custom code to perform a remote procedure call foreach and every application that needed remote communications.

Distributed computing systems often use a client/server architecture.Typically, a client is an application that runs on a personal computerand relies on a server to perform some operations. The server is acomputer on a network that manages network resources such as storagedevices, printers, or network traffic. Client-side operations are thoseoccurring on the client-side of a client/server system. For example, onthe World Wide Web, applets may be downloaded and executed on a clientand are client-side operations. Server-side operations occur on theserver of a client/server system. For example, management servicesperformed by the server occur on the server machine and are server-sideoperations. Client/server systems require communications and operationsto take place across a network. ORBs facilitate these communications andoperations across the network.

Microsoft has developed DCOM (Distributed Component Object Model) tosupport inter-application communications across networked computersystems. Another technology standard for inter-object communications isCORBA (Common Object Request Broker Architecture) established by theObject Management Group (OMG) which is a consortium sponsored by manycompanies, including Digital Equipment Corporation, Hewlett Packard, IBMand Sun Microsystems, Inc. CORBA defines how messages from one object toanother are to be formatted and how to guarantee delivery. The messagingin CORBA is performed by Object Request Brokers (ORBs). ORBs receivemessages, determine the location of the receiving object, route themessage to the receiving object, and perform all necessary platform andlanguage translations. In object oriented technology, a message istypically a request sent to an object to change its state or to return avalue. The object has encapsulated methods to implement the response tothe received message. Another system for inter-object communications isVoyager developed by ObjectSpace, Inc. Through technology such as DCOM,CORBA, and Voyager, objects can communicate with remote objects residingin other computer platforms connected by a network.

The existence of different ORBs from different developers has resultedin several different communication protocols for transmission andreception of messages across a network. For example, CORBA uses acommunication protocol called Internet Inter-ORB Protocol (IIOP). DCOMuses a communication protocol called object Remote Procedure Call(ORPC), and Voyager uses a communication protocol called Voyager RemoteMessaging Protocol (VRMP). The communication protocol used by aparticular ORB may be referred to as its native protocol or nativeformat. Conventional remote proxies generally have the communicationprotocol hard coded within the proxy.

CORBA compliant ORBs utilize stubs and skeletons to provide inter-objectcommunications across a network. The stub is on the requestor side andsends messages across the network to a skeleton on the remote objectside. The stub and skeleton take care of certain communication detailsfor the proxy on the requestor side and the object on the remote objectside. CORBA compliant ORBs generally use a utility to generate a stuband skeleton for each class using information provided in an InterfaceDescription Language (IDL) file for each object.

Enterprise Java Beans (EJB) is an object oriented programmingspecification developed by Sun Microsystems for use with its Javacomputer programming language. When using EJB, certain mechanisms areinterposed as an intermediate layer between a client object and a serverobject. This is generally accomplished by creating a wrapper classhaving the same methods as the object being wrapped and adding wrappingcode in each method of the wrapper class. An example of the wrappingcode would be adding security to the wrapped object such as limitingaccess to client objects with the proper password or key. Wrapperclasses are generally generated at run time and add additionalcomplexity to the distributed processing system in addition tonegatively impacting system performance.

In certain situations, existing software needs to be used withdistributing computing systems. Many conventional ORBs require aninterface for each class for proper communications across a network. Auser may not have access to the source code or may be restricted bylicense as to modifying the source code. Thus, the user may not be ableto add interfaces to class files within the existing software. Addinginterfaces allows classes to be used remotely in the distributedcomputing system.

SUMMARY OF THE INVENTION

Accordingly, a need has arisen for a system and method forcommunications in a distributed computing environment that providescommunications between both compatible and non-compatible object requestbrokers.

According to an embodiment of the present invention, a system forcommunications in a distributed computing environment is provided thatincludes an application layer, a proxy layer, a reference layer, and anobject layer. The application layer provides communications between anapplication and an operating entity. The proxy layer providescommunications between the application and a remote proxy. The remoteproxy is a local representative for a requested object where therequested object resides in an address space different from an addressspace where the application resides. The reference layer providescommunications between the remote proxy and the requested object. Thereference layer includes communication protocol details to supporttransmission of messages across a network linking the remote proxy andthe requested object. The object layer includes the requested object andmaintains a separation of communication protocol details within thereference layer.

The present invention provides various technical advantages overconventional systems for communication in a distributed computingenvironment. For example, one technical advantage is providingcommunications between object request brokers that use differentcommunication protocols. In addition, the present invention isolates thecommunication protocol details inside a reference layer so thatapplication programs and objects do not require information regardingthe location of a requested object or the communication protocol used toaccess the object. Other technical advantages may be readily apparent toone skilled in the art from the following figures, description andclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptiontaken in conjunction with the accompanying drawings in which likereference numbers indicate like features and wherein:

FIG. 1 illustrates a block diagram of a distributed object managementsystem;

FIG. 2 illustrates a flow diagram of a method for determining when todynamically generate remote proxy classes;

FIG. 3 illustrates a block diagram of a system for dynamicallygenerating remote proxy classes;

FIG. 4 illustrates a flow diagram of a method for dynamically generatingremote proxy classes;

FIG. 5 illustrates a block diagram of a distributed computing system;

FIG. 6 illustrates different communication layers within the distributedcomputing system;

FIG. 7 illustrates a block diagram of the communication layers of thedistributed computing system where a client-side object request brokerprovides a proxy layer and part of a reference layer;

FIG. 8 illustrates additional details of the reference layer provided bythe client-side object request broker;

FIG. 9 illustrates a block diagram of additional details of thereference layer provided by a server-side object request broker;

FIG. 10 illustrates a block diagram of a system for dynamicallygenerating remote proxy classes and other objects for the distributedcomputing system; and

FIG. 11 illustrates a block diagram of an interface generator.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 1, a distributed processing computer system generallyindicated at 10 is illustrated that comprises one or more server systems12 and one or more client systems 14. The client/server computer systemsallow for decentralized computing including the ability to manipulatedata which is resident on a remote system. The server system 12 andclient system 14 may comprise a personal computer, mini computer, mainframe computer, or any other suitable computer type device. In acomputer network environment, each computer is assigned a uniqueaddress. Therefore, if data, code or objects exist on a differentcomputer, it exists in a different address space.

The client system 14 requests access to data or services that may becontained on server system 12. Server system 12 may then process therequest and approve access as requested by client system 14. Clientsystem 14 is connected to server system 12 via a distributed objectmanagement system 16 operating across a computer network. Thedistributed object management system 16 handles the communicationsbetween client system 14 and server system 12. Without distributedobject management system 16, distributed processing could not take placesince client system 14 would not be able to determine the location of orobtain access to the requested data or services. The distributed objectmanagement system 16 may comprise Voyager, a distributed networkcommunications system developed by ObjectSpace, Inc., CORBA (CommonObject Request Broker Architecture), a technology for inter-objectcommunications developed by a consortium of companies, DCOM, aninter-application communications system for networked computersdeveloped by Microsoft, RMI, an inter-object communications system fornetworked computers developed by Sun Microsystems, Inc., or any othersuitable distributed object management system.

An object is an instance of a class within the programming methodologyof object oriented programming. The present invention may be implementedusing the Java language, developed by Sun MicroSystems, Inc., or anyother suitable computer language.

When an object class source code description is created in the Javalanguage, it is stored on a storage device as a .java file. Uponcompilation, the object class executable code is represented as a .classfile on the storage device. When an object is needed, a new instance, asprescribed by the .class file is created, and it is then referred to asan object. Server system 12 may contain one or more subject objects 18for which client system 14 may issue a request for access. In such acase, subject object 18 is the subject of client system's 14 request.Client system 14 may contain one or more local objects 20. Local object20 can itself be a subject object, and subject object 18 can itself be alocal object depending on what computer, or address space, is making therequest for access. For purposes of illustrating the present invention,local object 20 and subject object 18 exist in different address spaces.However, both local object 20 and subject object 18 could reside on thesame computer and still invoke the system and method of the presentinvention.

Local object 20 may request access to subject object 18. This requestinvokes the distributed object management system 16. In order to isolatethe distributed processing communication requirements from local object20, a remote proxy object 22 may be created on server system 12 andloaded onto client system 14. Remote proxy object 22 has an interfaceand list of methods identical to subject object 18. Remote proxy object22 is so named since it is remote from subject object 18, and itprovides a local representative for an object which may reside in adifferent address space. Remote proxies in general are responsible forencoding a request and its arguments and sending the encoded request tothe subject object that may exist in a different address space. Remoteproxies also hide the location of the subject object from the requestinglocal object. Therefore, any local object can assume, from an accesspoint of view, that any object it needs is local. Local object 20communicates with remote proxy object 22 which then communicates withsubject object 18 via distributed object management system 16. By doingthis, local object 20 is unconcerned with the location of subject object18.

Currently, a system developer must anticipate all necessary remoteproxies and create the remote proxy classes. Some distributed objectmanagement systems have a utility which augments the build process byallowing remote proxy classes to be built when the system is compiled.Although this process minimizes the system developer's effort, it stillinvolves system developer intervention, computer resources and time.Another disadvantage with current distributed object management systemsis that these remote proxy classes must be kept in sync with the subjectclasses as the subject classes and interfaces are modified. Anotherdisadvantage with current distributed object management systems is thatall remote proxy classes must be stored on the computer and availablefor use when needed. This creates high overhead in developer effort,computer storage and processing requirements.

In contrast, a system constructed using the principles outlined in thispatent application dynamically generates remote proxy classes as neededat run-time. There are several advantages of this method. The primaryadvantage is reduced system development time since the system developerdoes not have to manually generate remote proxy classes when the systemis initially compiled or manually regenerate remote proxy classes eachtime a subject object class is modified. The system also reducescomputer program storage requirements since remote proxy classes are nota permanent part of the operating environment. It also minimizes compileand load time for the computer program since remote proxy classes do nothave to be generated at compile and load time. In order to optimizesystem performance, generated remote proxy classes remain in memoryuntil the distributed object management system is shut down.

Dynamic Generation of Remote Proxies

Referring again to FIG. 1, the dynamic generation of remote proxies maybe accomplished by parsing the .class or .java file for subject object18 and creating a .java file for remote proxy object 22 which containsthe interfaces and methods of the subject object 18. The Java compilermay then be invoked to compile the .java file into a .class file forremote proxy object 22. The compiled .class file can then be loaded intothe computer system via a class loader which is a standard element in aJava environment. A .class file must be loaded before it is availablefor use by distributed processing computer system 10. Once the .classfile is loaded, a new instance of the compiled .class file may becreated which will be remote proxy object 22.

The process of parsing the subject object 18 class (subject class 19) or.java file, creating a source code file for remote proxy class 23,compiling, loading, and creating a new instance may be excessively slowat run-time. In order to address this issue, a reflection process may beused on subject object 18 to determine its name, interfaces and list ofmethods and then to directly generate the byte codes that define theclass of subject object 18. The generated byte codes represent subjectclass 19. The byte codes are equivalent to the executable code stored ina .class file. The byte codes can then be loaded into the computersystem memory with the class loader. This embodiment eliminates the needto parse the .class file, create a .java source code file, and shell outthe .java file to a compiler since the byte code generation processoccurs as part of the dynamic generation of remote proxies. This entireprocess of dynamic generation of remote proxies will be discussed indetail with reference to FIGS. 2, 3 and 4.

Referring to FIG. 2, the process of determining whether a remote proxyis necessary is invoked via a request from local object 20 for access tosubject object 18. The method begins at step 24 where local object 20 onclient system 14 requests access to subject object 18 on server system12. This request could be for any object whether it is local or remoteand in a different address space. The system generates and utilizesremote proxy objects in all inter-object communication to provideadditional processing support. Thus, any communication between objects,regardless of their location, utilizes remote proxy objects. Theseremote proxy objects act as a middle man between the requested objectand the requesting object to provide additional processing functionalitysuch as increased security.

Referring again to FIG. 2, the method then proceeds to step 26 where therequested object is located on either client system 14 or server system12. The method proceeds to step 30 where a determination is maderegarding the need for a remote proxy class. If remote proxy class 23already exists on client system 14, then the method terminates sinceremote proxy classes are not removed from client system 14 until thedistributed object management system 16 is shut down. However, if remoteproxy class 23 does not exist on client system 14, the method thenproceeds to step 32 where the byte codes representing remote proxy class23 are generated on server system 12 and loaded into client system 14memory based on the name, interfaces and methods of subject object 18. Amethod for generating remote proxies is described in detail withreference to FIGS. 3 and 4.

FIG. 3 is a functional diagram of the portions of distributed objectmanagement system 16 that are used to create remote proxy classes asnecessary. Remote proxy generation control module 34 is invoked at step32 in FIG. 2. When the distributed object management system 16 invokesthe remote proxy generation control module 34, the method previouslydescribed has already determined that the remote proxy class 23 does notyet exist on client system 14. Remote proxy generation control module 34generates remote proxy 22 on client system 14 so local object 20 cancommunicate with subject object 18 via distributed object managementsystem 16.

As previously discussed, in object oriented programming, an object is aninstance of a class. Classes may be defined in a class hierarchy whereeach class inherits the attributes of all of its ancestors. Inheritanceis a concept that maps related classes onto each other in a hierarchicalway. This allows a descendant of a class to inherit all of its variablesand methods from its ancestors as well as create its own. The immediateancestor of a class is known as the class' superclass. Therefore, inorder to determine all of a class's attributes, all of the class'sancestors, or superclasses, should be determined.

To fully define a remote proxy for a subject object, remote proxiesshould be generated for each of the subject object's superclasses. Bygenerating these superclass remote proxies, the remote proxy for thesubject object will inherit all of the variables and methods of itsancestors, or superclasses. An alternative to generating superclassremote proxies includes adding all of the superclass methods andinterface requirements to the remote proxy class. By adding thesuperclass information to the remote proxy class, the need forgenerating superclass remote proxies is eliminated.

Referring again to FIG. 3, remote proxy generation control module 34first invokes reflection engine 36 to determine information regardingsubject class 19. The process of reflection operates on subject class 19which is the Java .class file for subject object 18. Although forillustrative purposes, subject object 18 and its Java .class file,subject class 19, exist on server system 12, subject class 19 couldexist on either client system 14 or server system 12. Therefore, thedynamic generation of remote proxy classes as described in the presentinvention could take place on either client system 14 or server system12.

Reflection is a process that determines what an object can do, how it isdefined, and how it communicates with other objects. Reflection mirrorsthe public view of an object to collect information to facilitate thecreation of proxies that resemble objects on the public view, but arevery different internally, or privately. The public view of an objectrepresents the information external objects must know in order tocommunicate with the first object. Proxies need to be reflections, orduplicates on the surface, of objects since proxies perform specifictasks such as controlling access to or communications with the objectsthey represent. Thus, proxies need to look like the object on theoutside, but on the inside, proxies contain unique computer code toaccomplish their assigned function. The reflection process is onlyconcerned with determining the public view of an object. Therefore, theinformation determined by the reflection process includes the following:name; list of implemented interfaces; list of methods; and superclassinformation.

Continuing with FIG. 3, reflection engine 36 issues queries againstsubject class 19, which is the .class file for subject object 18, todetermine each of subject class 19 superclasses, its name, itsinterfaces, and each of its methods. The results of these queries aretemporarily stored within remote proxy generation control module 34 asJClass information 38. JClass information 38 is a temporary storage areafor the name, superclasses, interfaces, and methods of subject class 19.JClass information 38 could also include the name, interfaces, andmethods of each of subject class 19 superclasses.

If the queries of reflection engine 36 determine that subject class 19has no associated interfaces, reflection engine 36 invokes interfacegenerator 250 to generate an interface for subject class 19. Thegenerated interface is associated with subject class 19 and added toJClass information 38. Interface generator 250 will be discussed indetail with reference to FIG. 11.

If subject class 19 has superclasses, a remote proxy may be firstgenerated for each superclass using the system and method described withreference to the present invention. After the superclass remote proxiesare generated, JClass information 38 contains the name, interface, andlist of methods for subject class 19. An alternate methodology forproviding superclass methods and interfaces for the remote proxy classis to add all superclass method and interface information to the remoteproxy class. By doing this, the need for separate superclass remoteproxies is eliminated.

Once the name, interface, methods, and superclass information aredetermined for subject class 19, a communication enabling module 40 addsto JClass information 38 the computer code necessary for remote proxyobject 22 to communicate with subject object 18 via distributed objectmanagement system 16. The communication enabling module 40 inserts thecomputer code into JClass information 38 which is the definition of allthe information that remote proxy object 22 needs to function withindistributed object management system 16.

Since a remote proxy's purpose is to communicate with a subject objectthat may exist either in a different address space or in the sameaddress space, the remote proxy contains essentially the followinginformation: interfaces identical to the subject object; a list ofmethods identical to the subject object; and computer code necessary forthe remote proxy to communicate with the subject object. In an alternateembodiment of the present invention, the remote proxy would contain allof the information mentioned above and the interfaces and methods of allof the subject object's superclasses.

At this point, JClass information 38 contains subject object's 18 name,interfaces, methods, and the computer code necessary for communicationswithin distributed object management system 16. JClass information 38could also contain the superclass information for subject object 18. Thenext function invoked by remote proxy generation control module 34 isbyte code generator 42. The purpose of byte code generator 42 is todirectly generate the executable code corresponding to JClassinformation 38. JClass information 38 is the definition of the Javaclass of which remote proxy object 22 is an instance. That is, JClassinformation 38 is the definition of remote proxy class 23. Byte codegenerator 42 reviews JClass information 38 and generates thecorresponding byte codes, or executable code, into remote proxy class 23which is equivalent to a Java .class file except that it is not storedon a permanent storage device.

Byte code generator 42 is a collection of Java classes that are capableof taking the description of the needed proxy class in JClassinformation 38 and directly generating the executable Java code inmemory. The function of byte code generator 42 is similar to that of aJava compiler. Like a Java compiler, byte code generator 42 generatesexecutable Java code. However, the inputs are different. A compilerrequires a source code file containing a string of bytes that is thesequence of statements for a Java object definition. The string of bytesis parsed by the Java compiler and translated into executable Java code.In contrast, byte code generator 42 takes general information regardingthe needed Java object and directly generates executable Java codewithout the need for the intermediate step of creating a Java sourcefile. This technique yields considerable time savings since severalsteps are omitted. For example, like a Java compiler, byte codegenerator 42 generates a hexadecimal “CAFEBABE” to indicate to the Javavirtual machine that a Java .class file begins at that point in memory.Byte code generator 42 is constructed in such a way that the byte codesare generated in the sequence required by the Java virtual machine.

For each Java construct, byte code generator 42 writes the appropriateheader information and byte codes representing the Java construct intocomputer memory. Thus, there is a block of code, or bytes, for each Javaconstruct. As described above, JClass information 38 contains thecomputer code necessary for communications within distributed objectmanagement system 16. Byte code generator 42 translates thiscommunications information into byte codes recognizable to the Javavirtual machine. When byte code generator 42 terminates, the string ofhexadecimal bytes necessary to define the proxy class has been stored inmemory as remote proxy class 23 which is equivalent to an executableJava .class file. The generated remote proxy class 23 is stored inmemory and does not go through the system file procedure. Remote proxyclass 23 has a unique name which is derived from subject class 19 name.For example, if subject class 19 is named “Foo.class”, its remote proxyclass 23 name would be “Foo_Proxy.class”.

Before remote proxy class 23 can be used, it must be loaded onto clientsystem 14 utilizing a class loader 46. Class loader 46 may comprise anynumber of suitable programs which exist in typical object orientedprogramming environments. The class loader 46 takes the generated bytesof remote proxy class 23 stored in memory and loads them into a classstructure which then can be instantiated to create remote proxy object22.

FIG. 4 is a flow diagram that illustrates the process of generating aremote proxy when invoked by step 32 in FIG. 2 and as represented ingeneral by the block diagram in FIG. 3. The method begins at step 48where the reflection engine 38 queries subject class 19 to determine itssuperclass. The method then proceeds to step 50 where a determination ismade regarding the existence of a superclass for subject class 19. If asuperclass is found for subject class 19, then the method proceeds tostep 52 where a determination is made regarding the existence of theremote proxy class on client system 14 representing subject class' 19superclass. If a remote proxy class does not exist for subject class' 19superclass, the method proceeds to step 54 where the remote proxy classis generated for subject class' 19 superclass by recursively invokingthe remote proxy generation control module 34. Thus, step 54 recursivelyinvokes the method illustrated in FIG. 4.

Referring to step 52, if the remote proxy class does exist on clientsystem 14 for subject class' 19 superclass, then the method proceeds tostep 56 (described below) since remote proxy classes already exist forall of subject object's 18 superclasses.

In an alternate embodiment of the present invention, instead ofrecursively generating remote proxy classes for each of subject class 19superclasses, the interfaces and methods of each of subject class 19superclasses are stored in JClass information 38 and are later used inthe generation of remote proxy class 23. In the alternate embodiment,steps 48-54 would not exist in their current form. Instead, these stepswould consist of determining the names, interfaces, and methods of allof subject class 19 superclasses and storing the information in JClassinformation 38.

Referring to step 50 if a superclass does not exist for subject object18, then the method proceeds to step 56 where reflection engine 36queries subject class 19 to determine subject class' 19 name andinterface. The method proceeds to decisional step 57 where a decision ismade regarding the existence of an interface for subject class 19. If aninterface does not exist for subject class 19, the NO branch ofdecisional step 57 proceeds to step 59 where interface generator 250generates an interface for subject class 19. The method then proceeds tostep 58 (described below).

If an interface does exist for subject class 19, the YES branch ofdecisional step 57 proceeds to step 58 where reflection engine 36queries subject class 19 regarding its methods. Reflection engine 36issues queries for each of subject class' 19 methods until all methodsare determined. For each of subject class' 19 methods, the softwaresystem determines the method name, return type, parameters, andexceptions and stores the information in JClass information 38.

The method then proceeds to step 60 where reflection engine 36 createsJClass information 38 from the name, interface, and methods informationdetermined in steps 56 and 58. The method then proceeds to step 62 wherecommunication enabling module 40 inserts in JClass information 38 thecomputer code, in the form of an expression tree, necessary for remoteproxy object 22 to communicate with subject object 18 via distributedobject management system 16.

The method then proceeds to step 64 where byte code generator 42generates the executable code representing JClass information 38 intoremote proxy class 23. The method then proceeds to step 66 where classloader 46 loads remote proxy class 23 onto client system 14 where it isnow available for use. The method then proceeds to step 68 where remoteproxy object 22 is generated as a new instance of remote proxy class 23which was loaded in step 66.

Communication Layers

Referring to FIG. 5, a distributed computing system is generallyindicated at 100. Distributed computing system 100 may comprise atypical client/server system. Distributed computing system 100 includesa client system 102 and a server system 104 linked by a network 106.Distributed computing system 100 may be any suitable distributedprocessing system including the previously described distributedprocessing computing system 10. Client system 102 and server system 104may be any suitable computing device such as a mainframe computer,personal computer, or portable computer. Network 106 may comprise anInternet or other suitable network connecting client system 102 withserver system 104. Distributed computing system 100 also includes aclient-side object request broker (ORB) 112 and a server-side objectrequest broker (ORB) 114. Client-side ORB 112 executes on client system102 and provides client-side communication support for distributedcomputing system 100. Similarly, server-side ORB 114 executes on serversystem 104 and provides server-side communication support fordistributed computing system 100.

Client system 102 includes a client application 108 that accesses aserver object 110 on server system 104. Server object 110 may also bereferred to as a target object or requested object since server object110 is the target of a request for access initiated by clientapplication 108. Client application 108 may be an application residenton client system 102, an application uploaded from server system 104, anapplet uploaded from server system 104, or any other suitableapplication or procedure. Client-side ORB 112 and server-side ORB 114communicate across network 106 to provide a communication link betweenclient application 108 on client system 102 and server object 110 onserver system 104. Client-side ORB 112 and server-side ORB 114 areresponsible for encoding messages into an on-the-wire format anddecoding the message upon receipt. An example of this type ofdistributed computing system would be the World Wide Web operatingacross the Internet. “On-the-wire format” as used here refers to theformat required for the communication protocol used by the receivingdevice or the receiving ORB. Client system 102 would typically be apersonal computer connected to the Internet. Server system 104 wouldtypically be a web server hosting web pages and other network resources.Client-side ORB 112 may be resident on client system 102, or it may beuploaded from either server system 104 or any other computing deviceconnected to network 106.

Referring to FIG. 6, communication layers of distributed computingsystem 100 are generally indicated at 130. Communication layers 130 arethe layers through which a request, or message, from client application108 passes as it proceeds to server object 110. The messages sentbetween client application 108 and server object 110 may include amethod invocation. The method invocation is a request from clientapplication 108 to invoke a particular method on server object 110 andmay include the server object name, the method name or number to beinvoked, and any other arguments or data needed by the invoked method.Communication layers 130 include an application layer 132, a proxy layer134, a reference layer 136 and an object layer 138.

Application layer 132 includes the primary application or procedurebeing executed by client system 102 and any interactions with anapplication controller such as a human operator at a computer terminal.An operating entity such as a human operator at a computer terminalinteracts with the primary application or procedure being executed inapplication layer 132 on client system 102. Application layer 132communications with the proxy layer 134.

Proxy layer 134 provides a local object on client system 102 for areferenced server object 110 on server system 104. The local referenceis a remote proxy that allows application layer 132 to ignore both thelocation of the server object 110 and the communication details involvedin communicating across network 106. The local object in proxy layer 134is referred to as a remote proxy as previously described. Proxy layer134 communicates with reference layer 136.

Reference layer 136 allows client-side ORB 112 to communicate withserver-side ORB 114 using the communication requirements of server-sideORB 114. The communication requirements, or communication protocol, forserver-side ORB 114 may not be identical to the communicationrequirements, or communication protocol, for client-side ORB 112. Thus,the communication details for distributed computing system 100 are keptin reference layer 136. Communication details include formulating theproper argument list using commands and syntax that may be unique toclient-side ORB 112 and encoding the resulting message into anon-the-wire format acceptable to server-side ORB 114. Server-side ORB114 receives and decodes the message from client-side ORB 112. Referencelayer 136 communicates the message to the object layer 138.

Object layer 138 receives the message and forwards it to server object110. Server object 110 performs the procedure or method requested by themessage and forwards the result through communication layers 130 back toclient application 108.

Reference Layer Abstraction

Referring to FIG. 7, the communication layers 130 of distributedcomputing system 100 are illustrated. Many object-oriented environmentsutilize an interface as an intermediary for a requested object. Theinterface defines the public view of the requested object. The publicview includes the arguments passed to and from the requested object inaddition to the methods available for invocation. Interfaces are used toprovide inheritance from multiple sources in the Java programminglanguage. Although the present embodiment uses interfaces, otherembodiments may not use interfaces.

When client application 108 requests access to server object 110, aremote proxy 154 is generated for a server object 110 as previouslydescribed. Remote proxy 154 has an interface, IProxy 152. In oneembodiment, remote proxy 154 is generated from a standard base proxyclass. Since Java allows inheritance from only one class, interfaces areused to allow remote proxy 154 to inherit methods and functionality fromserver object 110. Server object 110 has a server object interface 111.Remote proxy 154 may communicate with server object 110 through serverobject interface 111. Traditional ORB implementations hardcodeinformation about the communication protocol used to access serverobject 110 into the remote proxy. This requires different proxyimplementations for each communication protocol used in distributedcomputing system 100. The present invention removes the hardcodedcommunication protocol information from remote proxy 154 and places itin reference layer 136 where a reference object 158 handles thecommunication protocol details. Reference object 158 is bound to remoteproxy 154 as remote proxy 154 is generated. Since reference object 158resides in reference layer 136, application layer 132 and proxy layer134 do not need to know the particular communication protocol used tocommunicate with server object 110 or the specific location of serverobject 110. The communication protocol used by a particular ORB may bereferred to as the ORB's native protocol or native format. In aparticular embodiment, communication enabling module 40, referred to inFIG. 3, generates reference object 158 and places a link in remote proxy154 to reference object 158.

Reference object 158 has a separate implementation for eachcommunication protocol used in distributed computing system 100. Thedifferent communication protocols may be any suitable communicationprotocol including IIOP, ORPC, and VRMP as previously discussed. Aninstance of reference object 158 for the communication protocolassociated with server object 110 is bound to remote proxy 154 whenremote proxy 154 is generated.

In operation, client application 108 requests access to server object110. The request for access may include invocation of a method of serverobject 110. This request causes server-side ORB 114 to generate a remoteproxy 154 for server object 110 as previously described except that inthis embodiment, the computer code necessary for communications isreplaced by a link to an instance of reference object 158 for thecommunication protocol associated with server object 110. Remote proxy154 is loaded onto client system 102 where it is available for use byclient application 108. Communications between client application 108and server object 110 proceed by client application 108 communicatingwith remote proxy 154 through its interface IProxy 152.

The method of remote proxy 154 invoked by client application 108packages the arguments for the requested method and passes them toreference object 158 using its interface, IReference 156. Referenceobject 158 forwards the arguments to a streamer object (to be discussedin the following section) corresponding to the invoked method forencoding the arguments into a format corresponding to Reference object158 identifies the communication protocol associated with server object110. The arguments are passed through network 106 to server-side ORB114. Server-side ORB 114 receives and decodes the arguments and thenpasses the arguments to server object 110 where the requested method isprocessed. Server object 110 passes a result through server-side ORB 114across network 106 to reference object 158. Reference object 158 decodesthe result and passes it to remote proxy 154. Remote proxy 154 thenmakes the result available to client application 108.

Function Objects and Streaming Architecture

Referring to FIG. 8, additional details of the client-side ORB 112implementation and communication details are illustrated. In addition togenerating reference object 158, communication enabling module 40,discussed with reference to FIG. 3, may also generate a type object 170linked to proxy object 154 and inserted between proxy object 154 andreference object 158. Type object 170 represents the class of serverobject 110. Type object 170 defines the methods on server object 110 towhich remote proxy 154 has access. Type object 170 includes a set offunction objects 172 linked to type object 170. Set of function objects172 corresponds in number to a set of methods 190 associated with serverobject 110. There is one function object in set of function objects 172for each method in set of methods 190. The function objects in set offunction objects 172 are sorted in ascending order based on a positionof the corresponding method in set of methods 190. By placing methods infunction objects, each method can be invoked using a consistentinterface. Set of function objects 172 represents the methods in set ofmethods 190 that client application 108 may invoke.

In operation, when remote proxy 154 receives a method invocation fromclient application 108, proxy object 154 scans its associated typeobject 170 and invokes the function object in set of function objects172 corresponding to the invoked method. Each function object in set offunction objects 172 communicates the method invocation to referenceobject 158 through its interface, IReference 156. In one embodiment,reference object 158 utilizes a set of streamers 180 to format themethod invocation into format consistent with the communication protocolused by server object 110. In that embodiment, there is one streamer permethod per class. Thus, all instances of a class (all objects with thesame class) use the same streamer. Set of streamers 180 handles theencoding and transmission of arguments and results according to thecommunication protocol used by the receiving object or ORB.

The streamers in set of streamers 180 correspond in number to thefunction objects in set of functions 172. In one embodiment,communication enabling module 40, discussed with reference to FIG. 3,links a streamer corresponding to each function object in set offunction objects 172 to reference object 158. The streamer in set ofstreamers 180 receives method arguments and a method number fromreference object 158 and formats the method invocation for communicationacross network 106. Passing method or function number instead of methodname reduces the amount of data transmitted across network 106 therebyreducing the amount of time used for data transmission. Although someORBs may receive and process a method number, other ORBs may require amethod name. Set of streamers 180 creates and sends serially a group ofbytes corresponding to the method invocation initiated by clientapplication 108.

Communication enabling module 40 links streamers in set of streamers 180to reference object 158. In one embodiment, communication enablingmodule 40 verifies that an instance of a corresponding streamer existson client system 102 prior to linking reference object 158 to thestreamer. For example, if a method one streamer 182 has already beeninstantiated for method one of the class associated with server object110, communication enabling module 40 links reference object 158 to themethod one streamer 182. If method one streamer 182 has not beenpreviously instantiated, communication enabling module 40 instantiates amethod one streamer 182 and links it to reference object 158. Method 1streamer 182 may include the non-variable communications specificprogram code to provide communications between client-side ORB 112 andserver-side ORB 114. Each streamer in set of streamers 180 is connectedto network 106 so that data may be transmitted to server-side ORB 114.Upon receipt, server-side ORB 114 decodes the communication and forwardsthe method invocation to the appropriate method in set of methods 190.

Wrapping Mechanism

Referring to FIG. 9, details of server-side ORB 114 implementation andcommunication support for distributed computing system 100 areillustrated. Some object oriented environments use a wrapping approachto interpose an intermediate layer between client objects and serverobjects. One such approach is Enterprise Java Bean Containers. In thepresent invention, the generated classes associated with certainwrapping approaches such as Enterprise Java Beans are eliminated and thegenerated class functionality placed in specialized function objectsreferred to as EJB function objects. The generated class functionalitymay include security checking, error handling, transaction management,or any other suitable common functionality.

Server-side ORB 114 includes a reference object 200, a local reference202, a type object 204, and one or more EJB function objects 206. Uponreceipt of a message from client-side ORB 112, server-side ORB 114obtains a reference object 200 based on communication protocolinformation included in the message. Reference object 200 is analogousto, and functions as, reference object 158. Thus, server-side ORB 114locates a reference object 200 for the communication protocol used byserver object 110. The message received by server-side ORB 114 isformatted and streamed by a streamer in set of streamers 180specifically for receipt and processing by server-side ORB 114.Reference object 200 decodes the message from the on-the-wire format andreconstitutes the message for processing by server-side ORB 114.Reference object 200 then forwards the message to local reference 202.Local reference 202 includes address and type information for serverobject 110. Using that information, local reference 202 locates theappropriate type object 204 for server object 110. Type object 204represents the class of server object 110 and includes a function object210 for each method 190 accessible by client application 108.

Type object 204 is generated by server-side ORB 114 at the same timeserver-side ORB 114 dynamically generates remote proxy 154. An EJBfunction object 206 is interposed as a specialization of function object210. EJB function objects 206 are used since creating an instance of acommon class, EJB function, is less time-consuming and utilizes fewersystem resources than generating a wrapping class for certain wrappingapproaches used in object-oriented environments such as Enterprise JavaBeans. EJB function objects 206 may also be considered specializedfunction objects or wrapping objects. Type object 204 forwards themessage to the appropriate EJB function object 206 for preliminaryprocessing. Preliminary common processing may include security checking,error handling, transaction management, or any other suitable commonfunctionality. After the preliminary common processing is complete, EJBfunction object 206 invokes the requested method 190 in server object110.

After server object 110 processes the method invocation, the result issent back to client application 108 through essentially the samecommunication path except that reference object 200 uses an appropriatestreamer from set of streamers 220 to encode the result into theappropriate on-the-wire communication protocol format, and the streamersin set of streamers 180 in client-side ORB 112 are bypassed. Client-sideORB 112 locates the appropriate reference object 158 utilizingcommunication protocol information received with the result message. Setof streamers 220 operates in the same way as set of streamers 180.

CORBA Helperless Communications

A particular implementation of an object request broker is Common ObjectRequest Broker Architecture (CORBA). CORBA classes and structures arederived from Interface Description Language (IDL) definitions, andCORBA-compliant ORBs provide a utility to generate code to representthese classes and structures in a format native to the specificCORBA-compliant ORB implementation. Conventional CORBA ORBs also use theIDL definitions to generate support classes including a client-side stuband server-side skeleton. The client-side stub accepts local requestsfor access to a server-side target object and encodes the request fortransmission across a network to the server-side skeleton. Theserver-side skeleton decodes incoming requests and forwards the decodedrequests to the target object that resides on the server system.

The present invention eliminates the need for stubs and skeletons asused in conventional CORBA-compliant ORBs by using the classes andstructures generated from the IDL to provide an ORB-specificimplementation of the IDL classes and structures that includes theinformation needed to communicate with other ORBs. Thus, CORBA stubs andskeletons are not generated. The code generation utility inserts a typecode and communication protocol information into each generated class.The type code identifies a structure corresponding to the original IDLdefinition and provides communications support for communicationsbetween CORBA and non-CORBA ORBs.

When a remote invocation is made from a remote proxy 154 in aclient-side ORB 112 of the present invention, the reference layer 136queries the generated class and determines the associated type code andcommunication protocol information. The type code is used to identifythe type object 170 and the communication protocol information is usedto determine an appropriate reference object 158 to be used to formatthe request for transmission to a CORBA-compliant server-side ORB 114.The appropriate reference object 158 formats the request into IIOPformat. IIOP is the communication protocol used by CORBA ORBs. Thereference object 158 uses a streamer from set of streamers 180 totransmit the request across network 106 to server-side ORB 114.

When a remote invocation is received in a server-side ORB 114 of thepresent invention from a CORBA-compliant client-side ORB 112, theserver-side ORB 114 queries the target object 110 to determine theexpected format of the request. Remote invocations are transmitted fromthe CORBA-compliant client-side ORB 112 in IIOP format. The referenceobject 158 in the server-side ORB 114 then decodes the request into theexpected format and forwards the request to the target object 110.

Server-side ORB Object Generation

Referring to FIG. 10, server-side ORB 114 is illustrated summarizing thevarious object generation processes of server-side ORB 114 discussedwith reference to FIGS. 1-9. Server-side ORB 114 includes a remote proxygenerator 300, a client-side type generator 302, a client-side functiongenerator 304, a client-side reference generator 306, a client-sidestreamer generator 308, a server-side reference generator 309, aserver-side local reference generator 310, a server-side type generator312, and a server-side function generator 314. Upon receiving a requestfor access to server object 110, server-side ORB 114 generates a set ofobjects to be uploaded to client-side ORB 112. This set of objects isgenerated by remote proxy generator 300, client-side type generator 302,client-side function generator 304, client-side reference generator 306,and client-side streamer generator 308. The uploaded set of objects isused by client-side ORB 112 for communications with server-side ORB 114and access to server object 110. The uploaded set of objects includesproxy object 154, type object 170, set of function objects 172,reference object 158, and set of streamers 180. In another embodiment,the aforementioned uploaded set of objects is generated by theclient-side ORB 112 using processes equivalent to those used byserver-side ORB 114 in response to transferring a remote proxy instancegenerated by remote proxy generator 300 to the client-side ORB 112.

Remote proxy generator 300 is similar in structure and operation toremote proxy generation control module 34. In this embodiment,communication enabling module 40 inserts information into the remoteproxy class identifying the communication protocol utilized byserver-side ORB 114 so that reference object 158 may be located toencode and send a message from client-side ORB 112 to server-side ORB114. Remote proxy generator 300 generates proxy object 154. Remote proxygenerator 300 may also invoke interface generator 250 to remote enableclasses without interfaces. Interface generator 250 and remote enablingclasses without interfaces are discussed in the following section.

Client-side type generator 302 generates type object 170 using classinformation obtained from server object 110. Type object 170 representsthe class of server object 110 and includes an array of function objects172 that provide access to the methods of server object 110.

Client-side function generator 304 generates a set of function objects172 corresponding in number to the methods of server object 110. Eachmethod of server object 110 has a corresponding function object in setof function objects 172. By placing the methods within function objects,a standard object communication statement may be used which does notrequire knowledge of the location of server object 110 or thecommunication protocol used to communicate with server object 110.

Client-side reference generator 306 generates reference object 158.Reference object 158 represents the communication protocol used byserver-side ORB 114. Client-side reference generator 306 instantiates astandard reference class for the communication protocol utilized byserver-side ORB 114.

Client-side streamer generator 308 generates a set of streamers 180. Setof streamers 180 corresponds in number to the methods of server object110. Each method of server object 110 has an associated streamer objectin set of streamers 180. Each streamer object formats and streams anappropriate method invocation request for the associated method ofserver object 110. Each method on server object 110 may require adifferent argument list. Thus, separate streamer objects are used toaccommodate the different argument lists.

After server-side ORB 114 generates proxy object 154, type object 170,set of function objects 172, reference object 158 and set of streamers180, server-side ORB 114 uploads the packet of objects to client-sideORB 112 where they are stored for use in communicating with serverobject 110 through server-side ORB 114. In another embodiment, afterserver-side ORB 114 generates proxy object 154, proxy object 154 isuploaded to client-side ORB 112 where client-side ORB 112 generates typeobject 170, set of function objects 172, reference object 158 and set ofstreamers 180 and stores the generated items for use in communicatingwith the server object 110 through server-side ORB 114.

Server-side reference generator 309 generates reference object 200.Reference object 200 manages the decoding of messages and methodinvocations received by server-side ORB 114. Reference object 200 alsoforwards the messages and method invocations to the corresponding typeobject 204 associated with a server object referenced in the messagesand method invocations.

Server-side local reference generator 310 generates local reference 202based on the name and type of server object 110. Local reference 202allows an incoming message destined for server object 110 to communicatewith a local reference 202 within server-side object request broker 114before proceeding to invoking a method on server object 110.

Server-side type generator 312 generates type object 204 representingthe class of server object 110. Type object 204 is similar in structureand operation to type object 170.

Server-side function generator 314 generates function objects 210 orspecialized function objects such as EJBfunction objects 206. Functionobjects 210 or EJB function objects 206 correspond in number to themethods of server object 110. Each function object 210 or EJB functionobject 206 directly invokes a corresponding method on server object 110.Each EJBfunction object 206 is instantiated from a standard EJBfunctionclass that provides common functionality in addition to thefunctionality of function object 210. Unique functionality may be addedto each EJBfunction object 206 after it has been instantiated to providefor unique processing needs included in function object 210. Server-sidefunction generator 314 generates function objects 210 or EJBfunctionobjects 206.

Remote Enabling Classes Without Interfaces

Referring to FIG. 11, an interface generator 250 is illustrated for usein remote enabling classes without interfaces. A typical remote proxy154 resides in client system 102 and communicates through network 106with server object 110 using server object interface 111. Existing classfiles on server system 104 may need to be used remotely by clientapplication 108 on client system 102. Before the existing class file maybe used remotely, it should have an interface in order to comply withthe communication standards of typical ORBs. Interface generator 250generates an interface 254 for a class file 252. Interfaces provide forinheritance from multiple sources and ease of method invocation. Withoutinterfaces, a complex procedure using reflection is used to invokemethods directly on objects.

In one embodiment, interface generator 250 is a command linepredevelopment utility used to generate interfaces for classes on serversystem 104 that will be used remotely in distributed computing system100. In that embodiment, the software developer knows that certain classfiles 252 will be used remotely. The software developer providesinterface generator 250 with a list of class files 252 for whichinterfaces 254 are to be generated.

Interface generator 250 includes a class reader 256, a reflection module258, a naming module 260 and an interface generation module 262. Classreader 256 retrieves the first class file name from an input list andreads the associated class 252 from a class repository.

Reflection module 258 uses reflection on class 252 to determine a nameof the class, public methods of the class, and a signature for each ofthe public methods of the class. The reflection process may be anysuitable reflection process including Java reflection as previouslydescribed. The signature of each public method includes a name of themethod, arguments used by the method, a result value for the method, andexceptions of the method.

Naming module 260 creates a name for interface 254 using any suitablenaming convention. In one embodiment, the name for interface 254 iscreated by prepending the letter “I” with the name of class 252. Theinterface Ixxx is generated for a class named xxx, where xxx is anyclass name.

Interface generation module 262 generates an interface for class 252using the name of class 252, the public methods of class 252, and thesignature of each public method of class 252. Interface 254 is thenadded to the class file repository where it is available for use withindistributed computing system 100.

In another embodiment, interface generator 250 is used during thepreviously described dynamic generation of remote proxies. In thatembodiment, remote proxy generation control module 34 searches forinterfaces implemented by class 252 for which a remote proxy class 23 isbeing generated. The interfaces may include a standard interface such asjava.rmi.Remote or com.objectspace.voyager.IRemote. In addition, theinterface may include a default interface with an “I” name as previouslydescribed. If none of the interfaces is found, remote proxy generationcontrol module 34 invokes interface generator 250 through reflectionengine 36 to generate an interface 254 for a specified class 252. Afterthe interface 254 is generated, it is added to the class file repositorywhere it is available for use with an object having a class of class 252and when instantiating the remote proxy class 23 to give remote proxyobject 22.

Thus, it is apparent that there has been provided in accordance with thepresent invention a system and method for remote enabling classeswithout interfaces that satisfies the advantages set forth above.Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions, andalterations may be readily apparent to those skilled in the art and maybe made herein without departing from the spirit and the scope of thepresent invention as defined by the following claims.

1. A system for communication in a distributed computing environment,comprising: a client system having a client application; a server systemhaving a server object; a network connecting the client system to theserver system; a client-side object request broker, embodied on acomputer memory, executing on the client system and operable to provideclient-side communication support for communications between the clientapplication and the server object, the client-side object request brokerdivided into a plurality of communication layers including anapplication layer, a proxy layer, a reference layer, and an objectlayer, the reference layer operable to remove communication protocoldetails for accessing the server object from the proxy layer and placeinto the proxy layer a link to a reference object configured to managethe communication protocol details, the reference layer shielding theother layers from communication messaging protocol details used tocommunicate with the server object; a server-side object request broker,embodied on the computer memory, executing on the server system andoperable to provide server-side communication support for communicationsbetween the client application and the server object, the server-sideobject request broker having a different communication messagingprotocol than the client-side object request broker.
 2. A distributedcommunications system, comprising: an application layer, embodied on acomputer memory, on a client system for executing applications andapplets and for interacting with one or more users or operatingentities, the application layer providing communications betweenapplications or applets and users or other operating entities; a proxylayer, embodied on the computer memory, on the client system forproviding communications between the application or applet and a remoteproxy, the remote proxy residing in the client system and representing aserver object in a server system; a reference layer, embodied on thecomputer memory, for providing communication messaging protocol specificlinks with server objects existing on other computers, the referencelayer providing communications between the proxy layer and an objectlayer, the reference layer operable to remove communication protocoldetails for accessing server objects from the proxy layer, wherein theapplication layer and the proxy layer are not aware of communicationdetails in the reference layer, the reference layer including aclient-side object request broker executing on the client system and aserver-side object request broker executing on the server system, theclient-side object request broker having a different communicationmessaging protocol than the server-side object request broker; and antheobject layer, embodied on the computer memory, for providingcommunications between the server object and the reference layer.
 3. Amethod for communications in a distributed computing environment,comprising; requesting a method invocation on a server object residingon a second computer from an application in an application layerresiding on a first computer, the first computer and the second computereach including an object request broker having different communicationmessaging protocols; generating a remote proxy on the first computer;removing communication messaging protocol details for accessing theserver object from the remote proxy; placing the communication messagingprotocol details into the a reference object; forwarding the methodinvocation to the remote proxy in a proxy layer, the remote proxylocally representing the server object; forwarding the method invocationto a reference layer where a the reference object encodes the methodinvocation into a communication messaging protocol used forcommunications with the server object, wherein the application and theremote proxy are not aware of the communication messaging protocol thereference layer; transmitting the encoded method invocation through thereference layer where a second reference object residing on the serverobject's computer decodes the method invocation into a formatrecognizable by the server object; forwarding the decoded methodinvocation to the server object in an object layer; and invoking anassociated method on the server object.
 4. The method of claim 3,further comprising: forwarding a result of the method invocation on theserver object to the application.
 5. A system for communications in adistributed computing environment, comprising: an application layer,embodied on a computer memory, for providing communications between anapplication and an operating entity; a proxy layer for providingcommunications between the application in the application layer and aremote proxy in the proxy layer, the remote proxy being generated forlocally representing a requested object for interactions with theapplication, the requested object residing in an address space differentfrom an address space of the application; a reference layer, embodied onthe computer memory, for providing communications between the remoteproxy and the requested object, the reference layer including areference object having communication protocol details to supporttransmission of messages across a network linking the remote proxy andthe requested object, the reference layer operable to remove thecommunication protocol details placed into the remote proxy foraccessing the requested object and insert into the remote proxy a linkto the reference object, wherein the application layer and the proxylayer are not aware of the communication protocol details in thereference layer, wherein the reference layer includes a client-sideobject request broker executing on a client system and a server-sideobject request broker executing on a server system and a networkconnecting the client system to the server system, the client-sideobject request broker and the server-side object request broker havingnon-compatible communication messaging protocols; an object layer,embodied on the computer memory, including the requested object, theobject layer providing a separation of communication messaging protocoldetails in the reference layer.
 6. The system of claim 1, wherein theapplication resides in the application layer.
 7. The system of claim 1,wherein the operating entity interacts with the application in theapplication layer.
 8. The system of claim 1, wherein the proxy layershields the application layer from a location of the requested objectand a communication messaging protocol used to communicate with therequested object.
 9. The system of claim 1, wherein the reference layershields the application layer, the proxy layer, and the object layerfrom communication messaging protocol details used to send messagesbetween the application and the requested object.
 10. The system ofclaim 1, wherein the requested object resides in the object layer. 11.The system of claim 1, further comprising a reference object residing inthe reference layer, the reference object operable to provide thecommunication messaging protocol details used for communications withthe requested object.
 12. The system of claim 1, wherein the applicationlayer exists on a client system; the proxy layer exists on the clientsystem; the reference layer exists on the client system and a serversystem; and the object layer exists on the server system.
 13. The systemof claim 1, wherein the reference layer uses the communicationsmessaging protocol of the server-side object request broker.
 14. Acomputer-implemented method for communications in a distributedcomputing environment, comprising: requesting a method invocation for amethod of a server object on a server computer at a server system by anapplication on a client computer at a client system, the server systemincluding a server-side object request broker having a differentcommunication messaging protocol than a client-side object requestbroker on the client system; generating a remote proxy on the clientsystem to locally represent the server object; forwarding the methodinvocation to the remote proxy on the client system; forwarding themethod invocation to a first reference object from the remote proxy, thefirst reference object residing on the client system; removingcommunication messaging protocol details for accessing the server objectfrom the remote proxy; placing the communication messaging protocoldetails into the first reference object; encoding the method invocationinto a communication messaging protocol used for communications with theserver object, the communication messaging protocol being identified bythe first reference object, wherein the application and the remote proxyare not aware of the communication messaging protocol in the firstreference object; transmitting the encoded method invocation across anetwork; receiving the encoded method invocation in a second referenceobject on the server system; decoding the encoded method invocation intoa format recognizable by the server system; forwarding the decodedmethod invocation to the server object; invoking the method on theserver object.
 15. The method of claim 14, further comprising forwardinga result on the method invocation on the server object to theapplication.
 16. The method of claim 14, further comprising generating aremote proxy for the server object and placing the remote proxy on theclient system.
 17. The method of claim 14, wherein transmitting theencoded method invocation includes serially sending each byte of theencoded method invocation from the client system to the server system.18. The method of claim 17, wherein receiving the encoded methodinvocation includes reconstituting the encoded method invocation fromthe serially received bytes.
 19. A client system comprising: a clientapplication, embodied on a computer memory, that is executable by theclient system in an application layer; and a client-side object requestbroker, embodied on the computer memory, that is operable to supportcommunications between the client application and a server object via anetwork, the client-side object request broker having a plurality ofcommunication layers including a proxy layer and a reference layer, thereference layer operable to remove communication protocol details foraccessing the server object from the proxy layer and insert into theproxy layer a link to a reference object configured to manage thecommunication protocol details such that the application layer and theproxy layer are not aware of the communication protocol details used tocommunicate with the server object, wherein the client-side objectrequest broker uses a different communication protocol than aserver-side object request broker that supports the server object. 20.The client system of claim 19 wherein the client-side object requestbroker resides in an address space that is different than an addressspace of the server-side object request broker.
 21. The client system ofclaim 19 wherein the reference layer is operable to provide a link tothe server object.
 22. The client system of claim 19 wherein a locationof the server object is hidden from one or more of the other layersusing a remote proxy.
 23. The client system of claim 19 wherein theproxy layer includes a remote proxy that is dynamically generated duringrun time.
 24. A server comprising a server-side object request brokerthat: is embodied on a computer memory; resides in a different addressspace from a client system having client-side object request broker; andis operable to provide access to a server object requested by theclient-side object request broker to the client-side object requestbroker, the client-side object request broker configured to removecommunication protocol details for accessing the server object from aproxy layer at the client system and replace the communication protocoldetails with a link to a reference layer at the client system to cause aclient application and a remote proxy at the client system to be unawarethat the server object was obtained from the different address space.25. The server of claim 24 wherein the server-side object request brokeris configured to communicate with the client-side object request brokervia a network.
 26. The server of claim 24 wherein the server-side objectrequest broker uses a messaging protocol that is different than amessaging protocol used by the client-side object request broker.